Fuzzy Database Matching

ABSTRACT

A method of improving the speed with which a sample such as a biometric sample can be fuzzily matched against records in a database, comprises extracting characteristics from the sample, and using those extracted characteristics as indexes ( 70 ) to address a lookup table ( 25 ). Each row within the lookup table points to an individual record occurrence list ( 28, 30, 32 ) which contain details of not only the stored records from which the given characteristic can be extracted, but also those records having an extracted characteristic which are within a defined proximity to the said characteristic. Characteristics are extracted from the sample record, and a given stored record is identified as being a possible match with the sample if it appears in a required number of record occurrence lists.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No.11/585,358 filed Oct. 23, 2006, the contents of which are herebyincorporated by reference. Furthermore, U.S. application Ser. No.11/585,358 was filed concurrently with U.S. application Ser. No.11/585,365 entitled “Fast Database Matching”, the contents of which ishereby incorporated by reference.

FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT

None.

TECHNICAL FIELD

The invention relates to the field of database systems. In particular,it relates to a method and system for improving the speed with which acandidate record may reliably be fuzzily matched against a record withinthe database.

BACKGROUND OF THE INVENTION

There is increasing need within a variety of fields to be able todetermine very rapidly whether or not a particular sample record alreadyexists within a large database, and if so to identify one or morematches. One particular field is biometrics, in which the requirement isto determine whether or not the individual who has provided a particularbiometric sample is already in the database.

Databases of the type described can be extremely large, and it may beimpractical to attempt a full match analysis between the sample recordand every one of the records within the database. In order to reduce thecomputational workload, a variety of pre-screening processes are in use,but many of these have very restricted fields of application since theyoften rely upon specific peculiarities of the matching algorithm or ofthe data that are to be matched.

An issue that arises particularly with the matching of biometric data,although it occurs in other applications as well, is that by theirnature biometric measurements are often not precisely reproducible. Forexample, repeated biometric measurements derived from the iris of aparticular individual are likely to vary somewhat, not least because theextent of iris occlusion by the eyelid and eyelashes will vary betweenimages. As a result, biometric matching normally relies upon the conceptof an approximate or “fuzzy” match, rather than on an exact match.

A typical scenario is the need to determine whether a particularindividual exists within a large database of individuals. For example,we may have an iris scan of an individual and want to know whether anational security database already contains one or more iris scans ofthe same individual. Because the sample iris scan and the stored irisscans are unlikely to be identical in all respects, one way of achievingthe necessary “fuzzy” match is to search over a region. Having convertedboth the sample and the stored records into codes, according to somepredefined protocol, we can attempt to find a match between a storedrecord and any code within a region which we consider to be sufficientlyclose to the sample code. Alternatively, we may attempt a match betweenthe sample code and any code within a search region which issufficiently close to one of the stored codes. In either case, the needto search over a region of codes when doing the fuzzy match maysignificantly slow down the matching process.

The present invention is provided to solve the problems discussed aboveand other problems, and to provide advantages and aspects not providedby prior database systems of this type. A full discussion of thefeatures and advantages of the present invention is deferred to thefollowing detailed description, which proceeds with reference to theaccompanying drawings.

SUMMARY OF THE INVENTION

According to a first aspect of the present invention there is provided amethod of identifying possible matches between a sample record and aplurality of stored records, the method comprising:

-   -   (a) Extracting from the stored records a plurality of        characteristics, said characteristics falling within a        characteristic space;    -   (b) For each said characteristic, maintaining a record        occurrence list of stored records from which said characteristic        and characteristics within a defined proximity to said        characteristic within said characteristic space have been        extracted;    -   (c) Extracting characteristics from a sample record; and    -   (d) Identifying a given stored record as being a possible match        with the sample if it appears in a required number of record        occurrence lists.

According to a further aspect of the invention there is provided asystem for identifying possible matches between a sample record and aplurality of stored records using a plurality of characteristics withina characteristic space, the system comprising:

-   -   (a) For each characteristic, a record occurrence list of stored        records from which said characteristic and characteristics        within a defined proximity to said characteristic within said        characteristic space have been extracted;    -   (b) A processor for extracting characteristics from the sample        record; and    -   (c) A processor for identifying a given stored record as being a        possible match with the sample if it appears in a required        number of record occurrence lists.

Such a method provides very fast candidate-matching at the expense ofsome additional effort when registering a new record within thedatabase. The trade-off is well worth while when matching is donefrequently in comparison with the frequency of registration of newrecords.

In some embodiments, separate processors may be used for matchingcharacteristics against sample records, and for identifying storedrecords as possible matches. These processors may be on separatecomputers, and may be remote from each other.

In one particular embodiment, the main data list including the fullcollection of stored records may be held separately from thecharacteristic list. That allows a local processor, to carry out theinitial analysis on a sample record such as a locally—obtained irisscan. Once a list of possible matches has been identified, that list canthen be passed to a remote server, where a more detailed analysis can becarried out by comparing the sample with the full encoded iris scans ofeach of the possible matches.

This approach has the further advantage that the designer of the systemdoes not need to distribute to a large number of users full copies ofthe entire database of encoded iris scans. Instead, each user simplyreceives a list of characteristics, which is enough for the initialanalysis to be carried locally. Where one or more possible matches arefound, the system may then be automatically report to a central locationwhere further analysis can be carried out against the full records.

Other features and advantages of the invention will be apparent from thefollowing specification taken in conjunction with the followingdrawings.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention may be carried in practice in a number of ways and somespecific embodiments will now be described, by way of example, withreference to the accompanying drawings, in which:

FIG. 1 shows the database structure according to an embodiment of theinvention;

FIG. 2 is a histogram exemplifying the matching process;

FIG. 3 is another exemplary histogram; and

FIG. 4 shows some exemplary hardware.

In the following detailed description, numerous specific details are setforth to provide a thorough understanding of claimed subject matter.However, it will be understood by those skilled in the art that claimedsubject matter may be practiced without these specific details. In otherinstances, well-known methods, procedures, components and/or circuitshave not been described in detail.

Some portions of the detailed description which follow are presented interms of algorithms and/or symbolic representations of operations ondata bits and/or binary digital signals stored within a computingsystem, such as within a computer and/or computing system memory. Thesealgorithmic descriptions and/or representations are the techniques usedby those of ordinary skill in the data processing arts to convey thesubstance of their work to others skilled in the art. An algorithm ishere, and generally, considered to be a self-consistent sequence ofoperations and/or similar processing leading to a desired result. Theoperations and/or processing may involve physical manipulations ofphysical quantities. Typically, although not necessarily, thesequantities may take the form of electrical and/or magnetic signalscapable of being stored, transferred, combined, compared and/orotherwise manipulated. It has proven convenient, at times, principallyfor reasons of common usage, to refer to these signals as bits, data,values, elements, symbols, characters, terms, numbers, numerals and/orthe like. It should be understood, however, that all of these andsimilar terms are to be associated with appropriate physical quantitiesand are merely convenient labels. Unless specifically stated otherwise,as apparent from the following discussion, it is appreciated thatthroughout this specification discussions utilizing terms such as“processing,” “computing,” “calculating,” “determining” and/or the likerefer to the actions and/or processes of a computing platform, such as acomputer or a similar electronic computing device, that manipulatesand/or transforms data represented as physical electronic and/ormagnetic quantities and/or other physical quantities within thecomputing platform's processors, memories, registers, and/or otherinformation storage, transmission, and/or display devices.

For the sake of clarity the description below will be directed toward anexemplary embodiment in the biometric field. In the embodiment to bedescribed, an iris scan has been taken of a particular individual, andthe need is to determine whether another iris scan of the sameindividual already exists within a large database such as a nationalsecurity database.

It will of course be understood that this particular example is simplyused to illustrate the general principles behind the invention, and thatthe same techniques will be equally applicable in other fields. Theinvention in its broadest form is not restricted to any particular classor type of data held within the database, nor to the details of thematching algorithms that are used.

DETAILED DESCRIPTION

While this invention is susceptible of embodiments in many differentforms, there is shown in the drawings and will herein be described indetail preferred embodiments of the invention with the understandingthat the present disclosure is to be considered as an exemplification ofthe principles of the invention and is not intended to limit the broadaspect of the invention to the embodiments illustrated.

The database structure of the exemplary embodiment is shownschematically in FIG. 1. Details of particular individuals are heldwithin a case list or table 16, each row 17 of which represents aspecific iris scan of a specific individual. Ideally, each individualwill be represented by a single iris scan, but of course in a typicalnational security database, there will in practice be multiple scans ofat least some individuals. Each row or iris scan record include columns18, 20, 22, which respectively hold a unique iris scan reference numberfor use within the system, the name of the individual, where known, andan external identifier such as a national security or social securitycode.

The full iris scan for each record is held within a separate data listor table 10, each row 11 of which represents an individual scan. Thistable consists of two columns, the first 12 being the unique referencenumber, mentioned above, and the second 14 holding the complete scan insome suitable encoded form. Where necessary, the original raw scan, asimaged, may also be stored as well. More generally, the column 14 may beconsidered to hold some encoded representation which uniquely identifiesa specific scan or other biometric record of a particular individual.

Each registered case (iris scan) is classified according to a pluralityof attributes, characteristics or codes, these being extracted orderived either from the raw iris scans or more typically from theencoded scan data 14.

The codes may, but need not, be representative of human-identifiablecharacteristics of the scan. For example, some of the codes could berepresentative of eye color, with others being representative of suchcharacteristics as the amount of color and intensity variation withinthe iris. Alternatively, the encoded scans 14 may be treated as a puredata stream, with the codes simply resulting from some function orfunctions applied to the data stream. Apart from the hash functionalready mentioned, a further possibility would be to search for thepresence or absence of specific groups of bits within the data stream.In any event, it will be understood that multiple codes will typicallybe extracted from each individual record 11.

To facilitate the use of these codes as indexes (as will be described inmore detail below) the codes are typically constrained to be numeric,and to lie within a particular predefined range. In a biometricapplication, for example, the codes might for example be defined by 16binary bits, allowing 65536 possible codes to occur. Preferably, thefunctions or operations which generate these codes from the raw orencoded data are limited in their possible range of outputs so that onlythe desired codes are possible. Alternatively, the actual range ofoutputs is remapped to a list of numeric codes within the desired range.A mapping table (not shown) may be used if required. In the examplebeing described, it will be assumed that the available codes P_(n)areintegers, in the range 0 to 65535, with each being stored as a 16-bitcode. Thus, P1=001, P2=010, P3=011, P4=100, P5=101 and so on, up to thefull 16 bits.

To categorize the codes according to the cases (iris scans) in whichthey appear, a plurality of lists or tables 28 is maintained, one foreach of the possible 65536 codes. For simplicity, only five of theselists are shown in FIG. 1. As may be seen, the list 40 for the codevalue 1 contains just a single row, indicating that only name Agenerates this code. The list 41, representing code value 2, contains nodata since in the present example none of the registered iris scansgenerates that code. The lists 42, 43, representing respectively codevalues 3 and 4, each relate just to a single scan. The table 44indicates that iris scans for names A and B each generate code value 5.

Although not essential, it is generally preferred that each of thetables or lists 28 contains in each row 29 simply the unique reference18 to a single record which corresponds to the relevant code.

In addition to the lists 28, a second series of lists 30 is maintained,each of these lists relating not simply to an individual code but ratherto those codes which are a given distance from the corresponding basecode, according to some desired metric such as the Hamming distance.

For reference in the example given by FIG. 1, the Hamming distancesbetween the codes 1 to 5 are given in Table 1. The Hamming distance isthe number of bits that are different between two codes. For example theHamming distance between codes 1 and 2 is 2, because 2 bits are changedbetween the code for 1 (001) and the code for 2 (010).

1 2 3 4 5 Codes (001) (010) (011) (100) (101) 1 0 2 1 2 1 2 2 0 1 2 3 31 1 0 3 2 4 2 2 3 0 1 5 1 3 2 1 0

Table 1. Hamming Distances Between the Binary Codes for Numbers 1 to 5

In the example shown, the tables 30 contain data relating to those caseswhich resolve to a code having a Hamming distance of exactly 1 from thecorresponding base code of the tables 28. Thus, for example, the table51 includes data for all of those codes which are exactly H=1 distantfrom P1 (0001). If, however codes at H=1 already occur in table 40 theymay be omitted from table 51 for efficiency. In the example of FIG. 1,code 1 is H=1 distant from codes 3 and 5. The name D from the base listfor 3 qualifies, and the names A and B from the base list for 5 qualify.However, name A has already occurred in the base list for code 1, soonly names D and B are included in table 51. Likewise, the table 52includes data for all of those codes which are exactly H=1 distant fromP2 (0010), and so on. However, if codes at H=1 already occur in table41, they may be omitted from table 52 for efficiency. In the example,code 3 is H=1 distant from code 2, so that name D is added to table 52from the base list for 3. Because table 41 is empty, there are no codesat H=1 from code 2 to omit from table 52.

A third series of table 32 contain details of cases which resolve tocodes which are H=2 distant from the corresponding bases codes. Furtherseries of tables (not shown) for H=3, H=4 and so on may also beprovided, if required.

It will be appreciated that the Hamming distance has been used toillustrate the embodiment and that any other convenient metric may beused. The required metric (eg Hamming distance) may be chosen accordingto the particular application in hand, and may either be fixed or may beuser selectable. In more sophisticated embodiments (not shown) the codesmay be multidimensional, with the required metric being measured withina corresponding multidimensional space.

Whenever a new iris scan is to be registered within the database, itsdetails are added to the case and data lists 16, 10 and thecorresponding codes for the new scan are calculated and/or determined.The scan's unique reference number 18 is then added, as appropriate, toone or more of the individual lists 28, 30, 32. If desired, one or morenew codes may be added to the code list 24, in which case the individualtables 28 are automatically created, and each iris scan within thedatabase is checked to determine whether its reference number needs tobe added to one or more of the newly created tables.

We now turn to the task of matching, or in other words determiningwhether an unknown iris scan matches one of the scans 14 within thedatabase. Rather than matching the scan against the encoded data, whichwould be computationally lengthy, instead the sample is processed toextract from it one or more code values. By applying the same functionor functions that were originally applied to the registered scans, oneor more sample codes are generated (those codes of course in the presentexample all being integral and lying within the range 0 to 65535).

To find which scans correspond with each sample code, each code n isused as an index 70 to a look-up table 25, this table containingpointers P1, P2, P3 . . . which point to the respective areas in memorywhich hold the code value 1, 2 and 3 lists. If each of the listscentered on a particular nominal code value follow one another inmemory, only a single pointer (plus an offset) will be required.Alternatively, separate pointers could be provided for the respectivelists within the series 28, the series 30 and the series 32. Anotherpossibility would be for each of the lists 28 to have a pointer whichlooks to the corresponding list in 30, and so on.

Once the appropriate tables have been identified, the system thenproceeds to identify candidate matches by building up a histogram of thenumber of occurrences of each case across all of the tables of aparticular Hamming distance. FIG. 2 illustrates an example in which asample scan has generated code values 1 and 3, and in which candidatematches are to be identified using a Hamming distance of up to 1. Thisis achieved by looking at the records in the base tables 40, 42 for thecodes 1 and 3, along with the related H=1 tables 51, 53. The base codetables generate two hits, namely A and D while the H=1 tables generatethree additional hits A, B and D.

A threshold is applied to the count, and any record which scores atleast the threshold value is considered to be a candidate match. Here,if the threshold is taken as 1, the candidate matches are scans A, B andD. At a threshold of 2, the candidates are A and D.

FIG. 3 shows the histogram for the same sample, generating codes 1 and3, but this time tested against a Hamming distance of up to 2 Here, thehits from the base tables 40, 42 are A and D, the additional hits fromthe H=1 tables 51, 53 are A, B, and D, and the additional hits from theH=2 tables 61, 63 are B and C. Applying a threshold of 1 gives us A, B,C and D as candidate matches, whereas applying a higher threshold of 2returns A, B, and D as candidates.

Although the counts are shown in FIGS. 2 and 3 as histograms, it will beunderstood that other counting methods could equally well be used, andthat in any event the actual histograms would typically not be plotted.

In alternative embodiments (not shown) the second series of tables 30could include data not only from codes which are exactly H=1 distantfrom the corresponding base code, but instead all codes which are up tothat distance. In such an arrangement, each H=1 table would include allthe data of the corresponding base table, each H=2 table would includeall the data of the corresponding H=1 table, and so on.

The output response of the system may be tuned, according to theapplication, by selecting suitable values for the threshold and/orHamming distance. Either or both of these values could be fixed,programmatically varied, or user varied. In some applications it may beconvenient for the user to be able to select appropriate values ofeither or both of these parameters at run time.

In some applications, more complex matching algorithms may be envisaged.For example, different threshold values may be used for differentHamming distances. The system could also automatically select candidatesat a variety of Hamming distances, and compare or combine the respectiveselections at different distances to generate an improved composite listof candidate matches.

The threshold and/or Hamming distance selections may be determined,where necessary according to the extent to which the pre-selectionprocess needs to remove a large number of cases from consideration inorder to speed up the overall matching process. Although the use of asimple count and a fixed threshold is a convenient way of dividingpossible matches from non-matches, other algorithms could equally wellbe used. One possible approach, for example, would be to select as apossible match all of those cases having a characteristic count which ismore than a fixed percentage higher than the average characteristiccount taken across all cases.

Depending upon the size of the sample to be evaluated, it may not benecessary to use the sample in its entirety: a sub-section of the databe all that is necessary.

The selection of codes, the matching criteria and the size of sample tobe analyzed will in most applications be chosen so that there is anacceptably low risk of a false rejection.

Once a list of candidate matches has been selected, using one of theprocedures described above, a more detailed match may then be carriedout against each of the possibilities, using any convenient matchingalgorithm. In the example described, the sample scan may be comparedagainst the candidates within the database using some more sophisticatedbut slower algorithm.

In one embodiment, the database itself may be held on the same computeror at the same location where the preliminary and/or the final matchingtakes place. Alternatively, the process may be distributed, with thepreliminary matching being carried out according to a code list held ata local computer, and the preliminary matches being passed on to aremote computer for the detailed matching to take place. Such anarrangement allows the primary data list 10 (which includes the fulldata representing all the stored scans) to be held at a centrallocation, with a local machine needing to hold just the individual caseoccurrence lists 28, 30, 32.

In another embodiment, shown in FIG. 4, the process of the presentinvention may further be speeded up by using multiple computers orprocessors operating in parallel. A user computer 32 forwards a matchingtask to a controller 34 which splits it up and distributes it between aplurality of computers or processors 36. Each processor 36 may beinstructed to handle a particular code or group of codes; alternatively,the controller 34 may split up the work in some other way. Theprocessors 36 pass their results onto a consolidator 38, which finalizesthe selection of possible matches (for example using the procedureillustrated in FIGS. 2 and 3). The list of possibilities is thenforwarded as required, either to a computer or processor 42 whichcarries out the detailed matching or as shown by reference numeral 40back to the user 32 for further analysis.

It will, of course, be understood that, although particular embodimentshave just been described, the claimed subject matter is not limited inscope to a particular embodiment or implementation. For example, oneembodiment may be in hardware, such as implemented to operate on adevice or combination of devices, for example, whereas anotherembodiment may be in software. Likewise, an embodiment may beimplemented in firmware, or as any combination of hardware, software,and/or firmware, for example. Likewise, although claimed subject matteris not limited in scope in this respect, one embodiment may comprise oneor more articles, such as a storage medium or storage media. Thisstorage media, such as, one or more CD-ROMs and/or disks, for example,may have stored thereon instructions, that when executed by a system,such as a computer system, computing platform, or other system, forexample, may result in an embodiment of a method in accordance withclaimed subject matter being executed, such as one of the embodimentspreviously described, for example. As one potential example, a computingplatform may include one or more processing units or processors, one ormore input/output devices, such as a display, a keyboard and/or a mouse,and/or one or more memories, such as static random access memory,dynamic random access memory, flash memory, and/or a hard drive.

In the preceding description, various aspects of claimed subject matterhave been described. For purposes of explanation, specific numbers,systems and/or configurations were set forth to provide a thoroughunderstanding of claimed subject matter. However, it should be apparentto one skilled in the art having the benefit of this disclosure thatclaimed subject matter may be practiced without the specific details. Inother instances, well known features were omitted and/or simplified soas not to obscure the claimed subject matter. While certain featureshave been illustrated and/or described herein, many modifications,substitutions, changes and/or equivalents will now occur to thoseskilled in the art. It is, therefore, to be understood that the appendedclaims are intended to cover all such modifications and/or changes asfall within the true spirit of claimed subject matter.

1. A method of identifying possible matches between a sample record anda plurality of stored records, the method comprising: extracting fromeach of the stored records a plurality of index characteristics, saidindex characteristics falling within an index characteristic space;maintaining a look-up table defining said index characteristic space,said look-up table having a plurality of rows, each row corresponding toa unique index characteristic within said index characteristic space;maintaining a plurality of record occurrence lists, each said list beinglinked from a specific row in said look-up table corresponding to aspecific index characteristic, and each said list identifying thosestored records from which said specific index characteristic and indexcharacteristics within a defined proximity to said specific indexcharacteristics within said index characteristic space have beenextracted; extracting sample index characteristics from a sample record;using said sample index characteristics as indexes to address saidlook-up table to look up a corresponding plurality of record occurrencelists which are associated with said sample index characteristics;counting the number of occurrences of respective stored recordsidentified within said record occurrence lists; and identifying a givenstored record as being a possible match with the sample if said countfor said given stored record exceeds a required threshold.
 2. A methodas claimed in claim 1 in which the defined proximity is a definedHamming distance.
 3. A method as claimed in claim 2 in which the definedHamming distance is user-selectable.
 4. A method as claimed in claim 1in which the required number is a numerical threshold.
 5. A method asclaimed in claim 1 in which the required number is a function of theaverage number of record occurrence lists per stored record.
 6. A methodas claimed in claim 1 in which said plurality of index characteristicsdefines all index characteristics within the index characteristic spacethat are extracted from said plurality of stored records.
 7. A method asclaimed in claim 1 in which said plurality of index characteristicsdefines all possible index characteristics within the indexcharacteristic space that could be displayed by a sample record.
 8. Amethod as claimed in claim 1 in which the said plurality of indexcharacteristics is generated by applying an operation, such as a hash,to the stored records.
 9. A method as claimed in claim 1, includingapplying an operation to the sample record to generate one or moresample outputs, and using the sample outputs to address a lookup table,each row in said lookup table pointing to a record occurrence list. 10.A method as claimed in claim 1 in which as index characteristics areextracted a histogram is built up recording matches by stored record;and identifying records as possible matches from the histogram.
 11. Amethod as claimed in claim 1 including establishing a plurality ofdefined proximities, and maintaining a separate record occurrence listfor each index characteristic and proximity combination.
 12. A method asclaimed in claim 11 in which the identifying step uses those lists whichrelate to a user-selected defined proximity.
 13. A method as claimed inclaim 1 including the additional step of further analyzing therelationship between the sample record and each of the said possiblematches.
 14. A method as claimed in claim 1 in which the saididentifying step is divided between a plurality of parallel processors,each forwarding an association result to a consolidator, saidconsolidator identifying stored records as possible matches independence upon said association results.
 15. A system for identifyingpossible matches between a sample record and a plurality of storedrecords, the system comprising: a computer processor coupled to adatabase containing a plurality of index characteristics extracted fromsaid stored records, said index characteristics falling within an indexcharacteristic space; a look-up table defining said characteristicspace, said look-up table having a plurality of rows, each rowcorresponding to a unique index characteristic within said indexcharacteristic space; a plurality of record occurrence lists, each saidlist being linked from a specific row in said look-up tablecorresponding to a specific index characteristic, and each said listidentifying those stored records from which said specific indexcharacteristic and index characteristics within a defined proximity tosaid specific index characteristics within said index characteristicspace have been extracted; and whereby the system is configured to:extract sample index characteristics from a sample record, and use saidsample index characteristics as indexes to address said look-up table tolook up a corresponding plurality of record occurrence lists which areassociated with said sample index characteristics; count the number ofoccurrences of respective stored records identified by said recordoccurrence lists; and identify a given stored record as being a possiblematch with the sample record if said count for said given stored recordexceeds a required threshold.
 16. A system as claimed in claim 15 inwhich the computer processor includes a first processor for extractingsample index characteristics from a sample record and a second processorfor identifying a given stored record as being a possible match with thesample record.
 17. A system as claimed in claim 16 in which the firstprocessor is remote from the second processor.
 18. A system as claimedin claim 15 in which the first processor comprises a plurality ofparallel processors, each forwarding an association result to aconsolidator, said consolidator identifying stored records as possiblematches in dependence upon said associated results.